1. Field of the Invention
The invention is in the field of computer networks, and more specifically in the field of domain name services.
2. Related Art
The use of computer networks is expanding to include services that would previously have been associated with telephone networks. These services include, for example, voice-over-internet-protocol (VoIP) communications. As such, it is sometimes desirable to store telephone numbers in domain name system (DNS) data.
Standards have been proposed for storage of telephone numbers in DNS data or in association with DNS data. For example, a specification (RFC 3761) proposed by the Internet Engineering Task Force (IETF) describes a mechanism for storing telephone numbers using a fixed mapping between a telephone number and a domain name. In the IETF specification, a telephone number such as 1650 381 6000 is represented as a domain name as 0.0.0.6.1.8.3.0.5.6.1.e164.arpa. The number is reversed and each digit is treated as a separate DNS label. A higher level domain name, e.g., “e164.arpa,” is appended to the string of DNS labels representing the telephone number. In order to maintain conformity with other DNS labels, the IETF specification maintains the tradition that each DNS label comprises alphanumeric case insensitive characters.
There are a number of problems that can result from the above strategy. For example, each DNS label requires two bytes of data for storage to hold an alpha numeric representation of each digit. Thus, an eleven-digit telephone number requires 22 bytes of data storage to hold an alphanumeric representation of the telephone number digits, as well as further storage for higher level parts of the domain name. Each DNS label is also treated as a case insensitive alphanumeric and must be individually searched as such. Further, in a typical implementation, for each data record there are approximately 28 bytes of overhead data and 100 bytes of NAPTR (naming authority pointer) data related to the domain indexed by the data. NAPTR data may include IP addresses, protocols, telephone numbers, or the like. The storage requirements for overhead data and NAPTR data are implementation dependent.
An example of a prior art DNS record (i.e. database record including DNS data), generally designated 100, is illustrated in FIG. 1. Approximately 28 bytes of Overhead Data 110 are associated with each DNS Record 100. For illustrative purposes, the approximate size of each field within DNS Record 100 is shown as a number in parentheses and a Scale 140 is included to show the size of one byte in each figure. A Sub-domain Data 120, representative of an eleven-digit telephone number, requires 22 bytes, and Related Data 130 (e.g., NAPTR data, “A” or “AAAA” DNS data related to the specific sub-domain) may take 100 bytes. Sub-domain Data 120 is typically interpreted relative to a higher level domain label and thus is typically a “relativized” sub-domain. One hundred and fifty bytes are thus required for each DNS record indexed by Sub-domain 120. When space is also used for the domain name, storage of 200 million phone numbers may take up to 30 Gigabytes of data. A database of this size is more practically stored in a storage device such as a hard drive than in local memory (e.g., DRAM). As a result, database of this size would significantly inhibit the operation of domain name services because accessing a hard drive takes a substantially longer time than accessing local memory. Further, these longer access times are in conflict with the requirements of telephone systems, which have strict latency requirement in both terms of absolute response times and the standard deviation of response times. There is, therefore, a need for improved systems and methods of managing telephone number data in DNS systems.